This is the sixth and final installment of the behind-the-app series, showing the making of Well Tempered version 2.0.
Marketing and launch
When Well Tempered was first launched back in early 2009, the way I had understood the app store proposal was this: Apple would host and market my app, and take 30% of the sales. Boy was I wrong. The app store was never a marketing tool, and very few apps are promoted by Apple at all.
With version 2.0 coming up, I knew I could not expect Apple to do my marketing. Also, since this was not a new product, but an update, it would be a hard sell to get peoples attention. So this looked like an up-hill battle.
Many people will tell you that you should think of the marketing both before you start making the product and all the way through your development. I had been thinking very much of the user experience, and to me the marketing I had to do was to communicate this.
So while Well Tempered was finishing the localization job, and I was iterating through versions together with my beta testers, I began approaching bloggers and influential musicians to get them interested and want to tell people about Well Tempered and write about the app.
App marketing, building those relationships, is probably the job I have done least well at during the development of Well Tempered 2.0. Because after all my effort, on launch day and the following days, it was announced in four places. That made for the best sales day in Well Tempered history, and its top placement: 55th grossing app in the music category of the Danish app store for that day.
After the first day, it went downhill, and by the fourth day I was not selling any copies of Well Tempered. This was despite having my marketing material localized in 9 languages, despite having focused on accessibility, despite being a universal app, despite (in my humble opinion) being the best tuner out of the many tuners I had tried in the app store, and despite supporting the latest iOS technologies, including the Apple Watch. My marketing strategy needed a new angle.
So far, I had been focused on making the best tuner, especially for early music players, but also running it by rock and jazz musicians to make sure it worked well for them. I had reached out to 60 or so bloggers, members of early music societies, conservatory teachers and people I thought have an influence on people. Surely, having made Well Tempered really well would make them like it and tell people about it?
Well, some reported publicly about it and told me about a bit of the feedback they got from others. But for the most part, they never installed Well Tempered themselves. Apparently I could not get them excited enough to tap the link so that they could redeem their free copy and try it out. This part really surprised me, and going forward I think I will need to work at this slowly and steadily, so that for future updates, at least they will want to try it out.
I decided to try advertising. Advertising is one of these things I see every day, yet haven’t tried much myself. I ended up trying Facebook, since there I could target very specifically whom I wanted to reach. So I made an advertisement for my app where I included my video, and let it run for a week. The demographic was very narrowly defined to harpsichord players in English-speaking countries. The result after a week was depressing: I had seen no new sales. 1010 people had seen it on average 1,9 times, and 12 of them had bothered to play the video and 3 had decided to tap “like” on it. At the very end of the campaign Facebook told me it could be credited for one sale - but with no sales in that period, that was incorrect.
So now I had two failed strategies, and close to no downloads from people who found it in the App Store. The last point is no wonder, if you search for instrument tuner or chromatic tuner, chances are you won’t even find it, at least not for the first 15 pages of apps! I’ll need to do some research into how to rank better there, but this just confirmed my first point in this installment, I can’t expect the App Store to do the marketing for me.
For my third alternative, I tried giving away as many copies as I could, hoping, like I had at first, to generate some more awareness of the app, that people would talk about it. Also, I started posting more about Well Tempered in relevant Facebook groups. I was super-nervous about this: since I did not want to come across as spammy, I made sure to post in just one or two groups every other day or so, and be careful to follow up on comments I would get in those groups.
This actually turned out quite well: I would get a nice spike in my sales, and people were interested, asking questions and “liking” my post. This also led to a lot of support requests coming in as personal Facebook messages. I had not been expecting this amount of a support burden on an overall small amount of sales, but oh well, I would not let my customers down.
While most of the support was easy to help out with, a few of the comments I did get back were really helpful to make Well Tempered better. I was already in the process of making version 2.1, but the support messages gave me an attention to choices I had made that perhaps were not the best ones after all. And this was issues that I would have expected to be alerted about in the beta testing stage, so I must admit I was a bit embarrassed when I discovered they had a point. So version 2.1 will hopefully relieve most of their concerns.
This taught me a lesson about marketing apps that I don’t think I have heard before: even though I’m working on issues that I’m embarrassed about in the current version, I should not stop marketing the current version. I know the updates are coming, and all customers will get the improved version for free. Most of the new customers will not notice the issues I’m improving, and like the tuner. For those who do, well, an update is under way. So even though I was working on version 2.1, I continued to post to different Facebook groups.
And now we have reached today, but absolutely not the end of the journey. Well Tempered 2.1 is under way, and parallel to that I’m working on an update for iOS 9. And I’ll do my best to blog about it, so you can follow along on my journey. Thank you for having followed my series, and do contact me for any questions - I’ll do my best to blog my answer. :-)
Full index:
This is the fifth installment of the behind-the-app series, showing the making of Well Tempered version 2.0.
Localization
If you care about your instrument being in tune, and in tune being a tuning system that compliments your music, I really think you should use Well Tempered. That’s why I made the decision to localize Well Tempered so that it would be native to at least 70% of people with an iPhone or iPad, and then the second language to most of the rest. I thus localized the application to English, French, German, Spanish, Italian, Russian, Chinese, Japanese and Korean.
Thinking about localization, I found two really hard questions:
Starting off with the name, Well Tempered could be thought of as a brand name. If a French speaking person reads a review on an English blog and wants to try it out, I really want that person to find Well Tempered. Calling it Bien Tempéré would make that harder.
Then again, the name is based on Bach’s Well-Tempered Clavier, and that name already has a translation to French: le Clavier bien tempéré. And of course, the English name is a translation from German: Das Wohltemperierte Klavier. Keeping the enlighs translated name in German seemed absurd. In other languages, such as Korean, I was told by the translators they would use the English name. So I ended up with a mix: in some languages I kept the name, and in some languages it was translated. I was curious to see what difference it would make.
The data in my app is temperament names and temperament calculations. I was curious whether I should translate all the names, but since I had so many temperaments, where some perhaps had appropriate translations and some did not, I chose not to translate them. I have yet to get any feedback on this from my users, so the question still stands.
Apart from these questions, the translation process was smooth enough. I used Tethras that I already have a good relation with, and I think the level of service I got was excellent compared to the price I paid. After that I wanted to use my network to get musicians who had that language as their native tongue to look over the end product. This didn’t go very well as I still miss hearing back from most people that I asked. If something is amiss in a language, I expect I will hear about it.
Accessibility
I have been impressed by how much effort Apple has put into making iOS accessible to people with disabilities. With them making it so easy to make my app accessible, it was only natural for me to implement this for Well Tempered. Not only would I make sure it was accessible, but I would also make sure the accessibility labels were localized the same languages as the interface in general.
Unfortunately, I was not able to get people with disabilities in my test group - I would really have liked to have more input on this. So I ended up testing it myself, and I shipped something I was happy with for the languages I understand. I really hope to hear back from users with disabilities, preferably in many languages.
Testing
A side benefit of making Well Tempered accessible, is that this makes it more easy to make automated tests for it. I have earlier used Calabash a great deal, but for this project I wanted to use UI automation, since I wanted also to use it to prepare my screenshots for the App Store. I had found that I could use snapshot from fastlane.tools to take screenshot based on my UI tests.
If you have ever used UI automation, you’re probably rolling your eyes now, and you would not be surprised to know that this was my biggest mistake. I would make my scripts, and spend a good time making those scripts since I got no feedback from the editor. Not a good experience at all. While working on the script it would lock up midway, and after finishing it, it would not reliably run again. Some runs it would not complete, some it would only take black images.
So instead of getting frustrated and wasting time, I should have made real tests and used that to take images. I would explore going back to Calabash every now and then, but I didn’t get how to change the language of Calabash and how I should write my scripts for an app where also the accessibility was localized, so in the end I ended up without UI tests.
Well, in the end is perhaps overstating it, a little while later Apple released UI testing with iOS 9 and Xcode, so this is what I will be using now. It even allows me to test with localized accessibility labels. :-) And Felix who is behind fastlane.tools is already working on UI testing and screenshots for snapshot. I had a bit of an issue about how to launch my app in different languages, but that has been solved now, so I can build my comprehensive test set that I hopefully can reuse for the UI testing.
Thanks for following me this far. In installment six I’ll cover the launch of version 2.0, and talk about app marketing. Stay tuned!
Full index:
Implementation
This is the fourth installment of the behind-the-app series, showing the making of Well Tempered version 2.0.
In Well Tempered 1.0 I explained how Well Tempered got to be an iPhone app. For version 2.0 I wanted to make sure I integrate with all relevant parts of the iOS ecosystem. That meant implementing it so it would work well on all iPhone sizes and on the iPads, and if it made sense, also integrating the Apple Watch.
Version 1.0 had been compatible with the original iPhone, but keeping compability is expensive. So for version 2.0 I gave myself a clean slate, and set the current platform, iOS 8, as a base line.
I chose to make the app universal, meaning that it would support any iOS formfactor. While working with AutoLayout, I have not used size classes, preferring to have the UI shrink and grow and only change a little bit to accommodate the different sizes. I think this worked well for the different iPhone sizes, while there is perhaps still a little bit too much free room on the iPad.
An important part when designing an application is finding its logical units, and how they will compose. Up front it was important to me that defining your temperament should all be done on the main screen. So the topmost part of the screen was designed for that, leaving the bottom part to either the pitch pipe or the tuner. To make this modular, I implemented this as two view controllers within one main view controller. I must admit I am surprised on how non-trivial this was, or how hard AutoLayout would make this for me - especially if I wanted to recompose during rotation. I trust, though, that stack views in iOS 9 will do much to relieve the pain experienced there.
I chose to write my entire application in Swift. This was at a point in time when Swift 1.2 had just come into beta, and CocoaPods support for Swift was not entirely complete. My first patches for AudioKit were thus support for CocoaPods, and bug reports to Apple about the upcoming Xcode 6.2.
Using Swift is of course not only about changing the syntax of one language to write Cocoa in to another. With Swift came new concepts - or rather, concepts that I got to use more than what I was used to. Three to mention in particular are value types, protocol oriented programming and functional programming.
My interest in value types came out of Andy Matuschaks presentation at Realm. In short, it is about using structs instead of classes to store model data, thus letting data be just data. I thought this would be especially beneficial when implementing state restoration, something I view as an important part of being a good iOS citizen, yet something that many app developers find too complex in their apps and choose to neglect. I discovered, though, that I had to serialize them myself, having no good JSON or plist serializer at hand. However, I think my work paid off well when it came time to pass the application state to my Apple Watch companion app, and I learned a lot. I expect I’ll be encapsulating all my model data in structs rather than classes for the next few years.
I also found it really nice to encapsulate my model functions together with my structs, as well as having my structs conform to different protocols. Apple described this later, at WWDC 2015, as protocol oriented programming. That, btw, was a really good video, and you should see it. Thereafter, of course, you should read Crustys reply.
Functional programming, while not new to me, is much more natural to embed into my code when writing Swift than writing Objective C.
Finally, I thought I should write an Apple Watch extention to be able to remote control the application. I did this while reviewing Pearson publishing’s Learning WatchKit Programming book my Wei-Meng Lee. His book about WatchKit 1.0 is a brilliant starters guide. When I finally got an Apple Watch to try it out on, I was surprised by the speed of it - or rather the lack thereof. It had been intentionally slow on the simulator, and I was expecting Apple to have overdone the slowness. I did not expect that the real-life experience of the app would be even slower. Or rather, that the communication between the app UI and the app extension would be as slow as it was. I am definitely looking forward to reworking the Apple Watch companion as a watchOS 2.0 app.
In the next installment, I’ll talk more about implementation, and in particular the implementation of Localization and Accessibility.
Full index:
Design
In the first installment of this series, I told you that I had done the design for the first version of Well Tempered myself. But the design didn’t look great, and the logo was not selling the tuner either.
For this version, I wanted to have a better design. Not having learned, I thought I’d become a better designer and went to work, but having spent enough time with my sketches, I found that I should call in the professionals. I looked at a lot of designs people had made and asked for some quotes, providing my initial design, my wishes, a history of the project and its economy, and codes to be redeemed in the app store for my old version.
Out of a total of eight designers that got back to me, I chose to work with two. I really wanted to have multiple inputs, and was even contemplating doing two distinctive versions of the app. Oh boy, what a load of extra work that would have been! One of the two quickly became silent, though, so I ended up working only with Aleksandar from Serbia.
Working with Aleksandar was really a lot of fun. We did all of the work through 99designs, and I can really recommend it as a collaboration tool for design projects. 99designs concept is to solicit many designs and only pay for the one I really like. I opted not to go with this concept, trusting more in me finding designers and thinking I would feel bad for all the designs I would choose not to pay for. But 99designs got their cut by having the collaboration tools and by holding the payment until the end of the project.
Aleksandar isn’t a musician, but we had fun iterating through the designs. Whenever I thought something hard to explain to a non-musician, I would just shoot an iPhone video, put it on Dropbox and send him the link. I’m sure he knows a lot about how to tune an instrument now. He also ping-ponged with his musician-friends, and delivered a design that I thought looked really good. I’ll admit, it was in many ways very close to my initial sketches, and that worried me, as I’m not a skilled designer. But running it by other musicians, it got good feedback, and thus I went ahead with that.
But here was the first stumbling block - I got so caught up in ping-ponging about the design that I waited with implementing it. Yes, implementing right away before something is mature makes for code that is best thrown away, and has the risk of locking you into that design since it is easy to start resisting changes knowing the extra work it will bring. But in retrospect I really should have implemented parts of it, because as I started implementing the final design, I noticed there were lots of usability issues that we hadn’t worked through. I very was happy with the responsiveness with Aleksandar, even after we thought we were done, but I also reworked parts of it myself and asking for his thoughts on it.
Come back for the fourth installment of the Well Tempered behind-the-scenes story.
Full index:
Audio Frameworks
I ended the last installment of the Well Tempered behind-the-scenes story saying that the 1.x versions were live from early 2009 to mid 2015. It taking so long for version 2.0 to come out was never my intention. Well Tempered was my first released app as an iOS developer, and I don’t have count of how many applications in different versions and variations I would release until version 2.0 of Well Tempered was finally in the app store, so it wasn’t because I had stopped developing for the platform. Far from it. If anything, it was probably that I wanted too much - the second system syndrome was strong for this project.
I really wanted to deliver on making a tuner that would listen to what people played and told them how flat or sharp they were. I already had done the calculations to know where the target was with the pitch pipe, and I had implemented my own spectral tuner back in 2006, so how hard could it be?
Well, the original iPhone wasn’t a great place to calculate FFTs in real time. I believe the Accellerate framework (which I seem to remember was called VecLib at the time) was available with iPhoneOS 2.0, but I could not get it to perform well on my iPhone 3G, which still ran the original iPhone hardware but with a 3G modem.
When the iPhone 3GS came around, I did have a rudamentary implementation that would perform, but AudioQueue wasn’t that nice a framework to play ball with, and I never was able to get a precision I could accept. The code I wrote for this was hard to maintain, and debugging it and experimenting with it to try to increase precision drained my energy and interest from it so much so that I abandoned the code, not wanting to build a new release upon this.
The reason AudioQueue was written in C was not to have the overhead of Objective C. The overhead wasn’t much, but there was little room to spare. Since there was really no alternative to AudioQueue, I built some Objective C wrapping around it of my own, but was never happy with the performance. That is why I experimented every time I would see a new open source audio framework for the iOS platform. There were in particular three that drew my attention:
libPD, a Pure Data engine for iOS, was something that I gave a lot of attention. My original work had been done with Pure Data and Max/MSP, so this was a world I knew, and I was hoping I could bring over my earlier work and base a version 2.0 upon that. While I still find this project very interesting, I must admit I have yet to ship something built on that. I have used it for demos, both by myself, with friends and with co-workers, but never shipped anything with it.
The second project that I found amazing was novocaine, which provided a nice block-interface on top of AudioQueue, making a nice compromise between performance and convenience. But alas, I never could compute the frequencies just right with it, and after a bit of testing I discovered the examples wouldn’t play a clear sine tone. In the end, I abandoned it.
The third project that got me excited was AudioKit. AudioKit looked like a really nice framework on top of Csound. I was surprised to find I could use it in real time, as I’ve always seen people render sounds and music with it that could be played back afterwards. And with the nice examples that came along with it, I could easily prototype that I could get pretty far in what I wanted, enough to give me confidence that I could build my version 2.0 upon it.
AudioKit has a great maintainer and a very inclusive community with an active mailinglist. If you want to write audio software for iOS, you really should check it out. I hope to use it in many later projects, and plan to continue using it as the basis for Well Tempereds audio and audio analysis.
Come back for installment three of the Well Tempered behind-the-scenes story.
Full index:
Follow Me
Follow me online and join a conversation